Current error handling processes and systems do not foster a shared environment involving multiple functionalities. They generally exist for particular applications and cannot be utilized by multiple applications across business lines that are necessary to carry out the many activities within an organization. Additionally, the functionality of current error handling processes exists generally in mainframe systems and are not available via the Internet. Further, these systems handle errors at only one level of context.
For example, within business organizations, programming is often occurring in a componentized manner where there are different business units across an organization that are responsible for programming certain functionalities. These functionalities are required to be shared among the different units, so there is a need to move from one component to another component to conduct many of the automated business tasks.
In the framework of the insurance business, components involving software code and associated data, are developed, for example, for creating an insurance policy and for administering an accounting system. A customer may access the insurance company's website in an effort to add a new policy. The task of adding a new policy may also involve invoking or “calling” the accounting component, where the customer's existing account information is maintained.
In this process, if the customer or an insurance agent, for example, incorrectly enters data or if there is a problem associated with either the accounting or “Add Policy” software, an error message may appear that states, for example, “Your attempt to add a policy failed.” This is only one level of context. It identifies that the customer failed to add a policy but does not further explain whether the failure was a result of a problem with the account processing or incorrectly entered data. A message identifying an account processing failure or incorrectly entered data would be the second level of context and describes, for example, where the failure occurred.
Alternatively, if only the more detailed level of context is returned, without also providing a higher level of context, confusion may result, especially when a user is not aware of underlying processes that may have been invoked and are at the root of the problem. In the simple example provided above concerning the “Add Policy” scenario, there may not be much confusion with the lower level context, but when a structure of components calling several other components is implemented on a large scale, a failure may occur in a place the user was not even aware programming was being executed, and the more detailed context may not effectively communicate that the requested task was never performed due to an error.
Accordingly, there is a need for a standardized method and system for capturing errors at different levels of context across shared functionalities, that is simple to implement, and enables universal use of a variety of applications via a network.